cited in the Europea 
Report of EgJli/fZ. 
Your Ref.: 




WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 7 
G06F 9/00 



A2 



(11) International Publication Number: WO 00/23877 

(43) International Publication Date: 27 April 2000 (27.04.00) 



(21) International Application Number: PCT/US99/245 1 0 

(22) International Filing Date: 19 October 1999 (19.10.99) 



(30) Priority Data: 
09/175,079 



19 October 1998 (19.10.98) 



US 



(71) Applicant: OBJECTSPACE, INC. [US/US]; Suite 500, 14850 
Quorum Drive, Dallas, TX 75240 (US). 

(72) Inventors: GUTHRIE, Rhett, Davis; 4606 Cedar Springs 
#1525, Dallas, TX 75219 (US). GLASS, Graham, W.; 
15190 Prestonwood Boulevard #1025, Dallas, TX 75248 
(US). 

(74) Agent: FISH, Charles, S.; Baker & Botts, L.L.P., 2001 Ross 
Avenue, Dallas, TX 75201-2980 (US). 



(81) Designated States: AE, AL, AM, AT, AU, AZ, BA, BB, BG, 
BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK, EE, ES, FI, 
GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, 
KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, 
MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE. 
SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, UZ, VN, YU, 
ZA, ZW, ARIPO patent (GH, GM, KE, LS, MW, SD, SL, 
SZ, TZ, UG, ZW), Eurasian patent (AM, AZ, BY, KG, KZ, 
MD, RU, TJ, TM), European patent (AT, BE, CH, CY, DE, 
DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), 
OAPI patent (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, 
MR, NE, SN, TD, TG). 



Published 

Without international search report and to be republished 
upon receipt of that report. 



(54) Tide: SYSTEM AND METHOD FOR DYNAMIC GENERATION OF REMOTE PROXIES 




(57) Abstract 

A software system is disclosed which provides for dynamic generation of remote proxy classes at run time through a distributed object 
management system (16). The software system provides for a client system (14) and server system (12) which communicate via distributed 
object management system (16) which operates over a distributed computer network to allow communications between client system (14) 
and server system (12). Any inter-object communication will invoke a remote proxy generation control module (34) if a remote proxy 
class (23) does not already exist for the requested subject object (18). A remote proxy generation control module (34) is provided which 
first invokes reflection engine (36) to determine the applicable information of subject class (19). Next, a communication enabling module 
(40) determines and inserts the appropriate computer code to allow local object (20) to communicate with subject object (18) utilizing 
remote proxy object (22). After the system determines what information is required by remote proxy class (23), byte code generator (42) 
automatically generates the executable code containing remote proxy class (23). Finally, class loader (46) loads remote proxy class (23) 
onto the system and creates a new instance which is remote proxy object (22). 



BNSDOCID: <WO 0O23877A2_l_> 



FOR THE PURPOSES OF INFORMATION ONLY 



Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT. 



AL 


Albania 


ES 


Spain 


LS 


Lesotho 


AM 


Armenia 


FI 


Finland 


LT 


Lithuania 


AT 


Austria 


FR 


France 


LU 


Luxembourg 


AU 


Australia 


GA 


Gabon 


LV 


Latvia 


AZ 


Azerbaijan 


GB 


United Kingdom 


MC 


Monaco 


BA 


Bosnia and Herzegovina 


GE 


Georgia 


MD 


Republic of Moldova 


BB 


Barbados 


GH 


Ghana 


MG 


Madagascar 


BE 


Belgium 


GN 


Guinea 


MK 


The former Yugoslav 


BF 


Burkina Faso 


GR 


Greece 




Republic of Macedonia 


BG 


Bulgaria 


HU 


Hungary 


ML 


Mali 


BJ 


Benin 


IE 


Ireland 


MN 


Mongolia 


BR 


Brazil 


1L 


Israel 


MR 


Mauritania 


BV 


Belarus 


IS 


Iceland 


MW 


Malawi 


CA 


Canada 


IT 


Italy 


MX 


Mexico 


CF 


Central African Republic 


JP 


Japan 


NE 


Niger 


CG 


Congo 


KE 


Kenya 


NL 


Netherlands 


CH 


Switzerland 


KG 


Kyrgyzstan 


NO 


Norway 


CI 


Cote d'Tvoire 


KP 


Democratic People's 


NZ 


New Zealand 


CM 


Cameroon 




Republic of Korea 


PL 


Poland 


CN 


China 


KR 


Republic of Korea 


PT 


Portugal 


CU 


Cuba 


KZ 


Kazakstan 


RO 


Romania 


CZ 


Czech Republic 


LC 


Saint Lucia 


RU 


Russian Federation 


DE 


Germany 


U 


Liechtenstein 


SD 


Sudan 


DK 


Denmark 


LK 


Sri Lanka 


SE 


Sweden 


EE 


Estonia 


LR 


Liberia 


SG 


Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


sz 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Turkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UG 


Uganda 


US 


United Stales of America 


uz 


Uzbekistan 


VN 


Viet Nam 


YU 


Yugoslavia 


ZW 


Zimbabwe 



BNSDOCID: <WO 0023877 A2_l_> 



WO 00/23877 



PCT/US99/24510 



1 



SYSTEM AND METHOD FOR DYNAMIC GENERATION 
OF REMOTE PROXIES 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of 
software systems, and more particularly to an improved 
system and method for dynamic generation of remote proxy 
classes within a distributed object management system. 

BACKGROUND OF THE INVENTION 

Object oriented programming is a method of programming 
which abstracts a computer program into manageable 
sections. The key to object oriented programming is the 
concept of encapsulation. Encapsulation is a method by 
which the subroutines, or methods, that manipulate data are 
combined with the declaration and storage of that data. 
This encapsulation prevents the data from arbitrarily being 
accessed by other program subroutines, or objects. When an 
object is invoked, the associated data is available and can 
be manipulated by any of the methods which are defined 
within the object to act upon the data. The basic 
component of encapsulation is a class. A class is an 
abstraction for a set of objects that share the same 
structure and behavior. An object is a single instance of 
a class that retains the structure and behavior of the 
class. Objects also contain methods which are the 
processes by which an object is instructed to perform some 
procedure or manipulation of data which it controls. 
Classes may also be characterized by their interface which 
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defines the elements necessary for proper communication 
between objects. 

Distributed computing allows an object on one computer 
system to seamlessly communicate with and manipulate an 
obiect contained in a second computer system when these 
rrrputers are connected with a computer network. This 
• •/cr.d c:- ; puter system may also be referred to as another 
: - r,pric*L-. Sophisticated distributed computing systems 

• -v. r»-^-vvd the communications burden from the computer 
: : ; ram:- , v-r objects in an object oriented programming 

• v i rcr.rr.fr.* , and placed it in a mid-level operating system 
w:i:ch purpose is to manage communications across a computer 
m-iwork to facilitate a client's access to and manipulation 
o! data contained on a server system, for example, a 
computer remote to the user in a different address space. 

Distributed computing and object oriented programming 
have led to the development of distributed object 
management systems. When an object on a client computer 
system requests access to an object which exists only on a 
server computer system, the distributed obj-ect management 
system steps in to facilitate the communication between the 
two computer systems and, thus, between the two objects. 
The distributed object management system removes the 
requirement of the object on the client system 
communicating directly with the object on the server 
system. Instead, current distributed object management 
systems create a remote proxy object on the client system 
which models the interface of the object which exists on 
the server system. The client computer system which 
requested access to the remote object communicates with the 
remote proxy object which now exists on the client computer 
system. Therefore, the client computer system can operate 
as if it is communicating directly with a local obj ect . 
The remote proxy object contains the necessary 
communications information to allow the client computer 
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system to access and manipulate an object which actually 
exists on the server computer system. Remote proxies allow 
the client system to disregard the location of the 
requested object and the communication details. 
5 A proxy is an object which has an interface and method 

list identical to another object. However, it does not 
contain the same detail computer programming. Instead it 
contains communications requirements which allow the proxy 
to communicate directly with another object without the 

10 knowledge of the first object. Proxies can be used to 

control access to certain objects. They may also be used 
to remove the labor of distributed processing 
communications from local objects. For example, if object 
A which resides on a first computer system needs to 

15 communicate with object B which resides on a second 

computer system, object A must know the location of object 
B and have the necessary computer code to initiate 
communications with object B located on the second computer 
system. A proxy for object B located on the first computer 

20 system allows object A to simply communicate with the proxy 

of object B as if object B resided on the same computer. 
The proxy for Object B has all the necessary information 
and computer code to communicate with the real object B on 
the second computer system. This type of proxy is known as 

25 a remote proxy since it exists on a computer system remote 

from the computer system which contains the requested 
ob j ect . 

Systems heretofore known have required all possible 
remote proxies to be built when the software system is 

30 initially compiled and loaded onto a computer. This 

process can be very time consuming and the resultant remote 
proxies can require large amounts of computer storage. In 
addition, software system designers must predict every 
possible remote proxy which may be needed in the future so 

35 that it can be built when the software system is loaded. 
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This process does not allow a system to adapt to its usage 
and environment . 

SUMMARY OF THE INVENTION 
5 Accordingly, a need has arisen for a software system 

in the area of distributed processing which reduces the 
time and expense required to build, load and store a 
distributed object management system. 

According to one embodiment of the present invention, 

10 a software system is provided that comprises a client 

system and server system that communicate via a distributed 
computer network utilizing a distributed object management 
system. The distributed object management system also 
comprises a remote proxy generator to dynamically generate 

15 at run time remote proxy classes as needed for inter-object 

communications within the distributed computer network. 

One important technical advantage .of the present 
invention inheres in the fact that it decreases development 
time and increases developer productivity since the 

20 developer does not have to manually generate the remote 

proxy classes when the system is initially installed or 
when the subject class is modified in the future. Other 
technical advantages include reduced initial system build 
time and reduced disk storage space required to store the 

25 application programs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention and the advantages thereof, reference is now made 
30 to the following description taken in conjunction with the 

accompanying drawings in which like reference numbers 
indicate like features and wherein: 

FIGURE 1 is a block diagram illustrating a distributed 
object management system constructed according to the 
35 teachings of the present invention; 
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FIGURE 2 illustrates a flow chart of a method of 
determining when dynamic generation of remote proxy classes 
is needed according to the teachings of the present 
invention; 

5 FIGURE 3 is a block diagram illustrating dynamic 

generation of remote proxy classes according to the 
teachings of the present invention; and 

FIGURE 4 illustrates a flow chart of a method of 
dynamically generating remote proxy classes according to 
10 the teachings of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Referring to FIGURE 1, a distributed processing 
computer system generally indicated at 10 is illustrated 

15 that comprises one or more server systems 12 and one or 

more client systems 14. The client /server computer systems 
allow for decentralized computing which includes the 
ability to manipulate data which is resident on a remote 
system. The server system 12 and client system 14 may 

20 comprise a personal computer, mini computer, main frame 

computer, or any other suitable computer type device. In 
a computer network environment, each computer is assigned 
a unique address. Therefore, if data, code or objects 
exist on a different computer, it is said to exist in a 

25 different address space. 

The client system 14 requests access to data or 
services which may be contained on server system 12, 
Server system 12 may then process the request and approve 
access as requested by client system 14. Client system 14 

30 is connected to server system 12 via a distributed object 

management system 16 operating across a computer network. 
The distributed object management system 16 handles the 
communications between client system 14 and server system 
12. Without distributed object management system 16, 

35 distributed processing could not take place since client 
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system 14 would not be able to determine the location of or 
obtain access to the requested data or services. The 
distributed object management system 16 may comprise 
Voyager, a distributed network communications system 
5 developed by ObjectSpace, Inc., CORBA (Common Object 

Request Broker Architecture) , a technology for inter-object 
communications developed by a consortium of companies, 
DCOM, an inter-application communications system for 
networked computers developed by Microsoft, or any other 

10 suitable distributed object management system. 

The present invention teaches a system and method for 
generating proxies on local systems to facilitate access to 
objects on remote systems. An object is an instance of a 
class within the programming methodology of object oriented 

15 programming. The present invention may be implemented 

using the Java language, developed by Sun Micro Systems, 
Inc., or any other suitable computer language. 

When an object class source code description is 
created in the Java language, it is stored on a storage 

20 device as a .java file. Upon compilation, the object class 

executable code is represented as a .class file on the 
storage device. When an object is needed, a new instance, 
as prescribed by the .class file is created, and it then is 
referred to as an object. Server system 12 may contain one 

25 or more subject objects 18 for which client system 14 may 

issue a request for access. In such a case, subject object 
18 is the subject of client system's 14 request. Client 
system 14 may contain one or more local objects 20. It is 
important to note that local object 20 can itself be a 

30 subject object, and subject object 18 can itself be a local 

object depending on what computer, or address space, is 
making the request for access. For purposes of 

illustrating the present invention, local object 20 and 
subject object 18 exist in different address spaces. 

35 However, both local object 20 and subject object 18 could 
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reside on the same computer and still invoke the system and 
method of the present invention. The present invention is 
utilized in all inter-object communications regardless of 
their relative locations. 
5 Local object 20 may request access to subject object 

18. This request invokes the distributed object management 
system 16. In order to isolate the distributed processing 
communication requirements from local object 20, a remote 
proxy object 22 may be created on client system 14. Remote 

10 proxy object 22 has an interface and list of methods 

identical to subject object 18. Remote proxy object 22 is 
so named since it may be remote from subject object 18, and 
it provides a local representative for an object which may 
reside in a different address space. Remote proxies in 

15 general are responsible for encoding a. request and its 

arguments and tor sending the encoded request to the 
subject obj.ect which may exist in a different address 
space. Remote proxies also hide the location of the 
subject object from the requesting local object. 

20 Therefore, any local object can assume, from an access 

point of view, that any object it needs is local. Local 
object 20 communicates with remote proxy object 22 which 
then communicates with subject object 18 via distributed 
object management system 16. By doing this, local object 

25 20 is unconcerned with the location of subject object 18. 

As far as it is concerned, local object 20 is communicating 
directly with another local object, but in reality, it is 
communicating with subject object 18 which may reside in a 
different address space. 

30 Currently, a system developer must anticipate all 

necessary remote proxies and create the remote proxy 
classes. Some distributed object management systems have 
a utility which augments the build process by allowing 
remote proxy classes to be built when the system is 

35 compiled. Although this process minimizes the system 
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developer's effort, it still involves developer 
intervention, computer resources and time. Another 
disadvantage with current distributed object management 
systems is that these remote proxy classes must be kept in 
5 sync with the subject classes as the subject classes and 

interfaces are modified. Another disadvantage with current 
distributed object management systems is that all remote 
proxy classes must be stored on the computer and available 
for use when needed. This creates high overhead in 
10 developer effort, computer storage and processing 

requirements . 

In contrast, a system constructed using the present 
invention dynamically generates remote proxy classes as 
needed at run-time. There are several advantages of this 

15 method. The primary advantage is reduced system 

development time since the system developer does not have 
to manually generate remote proxy classes when the system 
is initially compiled or manually regenerate remote proxy 
classes each time a subject object class is modified. The 

20 system of the present invention also reduces computer 

program storage requirements since remote proxy classes are 
not a permanent part of the operating environment. It also 
minimizes compile and load time for the computer program 
since remote proxy classes do not have to be generated at 

25 compile and load time. In order to optimize system 

performance, generated remote proxy classes remain in 
memory until the distributed object management system is 
shut down. 

Referring again to FIGURE 1, the dynamic generation of 
30 remote proxies may be accomplished by parsing the .class or 

. java file for subject object 18 and creating a .java file 
for remote proxy object 22 which contains the interfaces 
and methods of the subject object 18. The Java compiler 
may then be invoked to compile the .java file into a .class 
35 file for remote proxy object 22. The compiled .class file 
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can then be loaded into the computer system via a class 
loader which is a standard element in a Java environment. 
A .class tile rr.uct be loaded before it is available for use 
by distrib^t- j processing computer system 10. Once the 
.class fa!*- : :> loaded, a new instance of the compiled 
.class file rr.ay be created which will be remote proxy 
ob j ect 22 . 

The prrcciii of parsing the subject object 18 .class 
(subject clui;:; 19) or . java file, creating a source code 
file for remote proxy class 23, compiling, loading, and 
creating a new instance may be excessively slow at run- 
time. In order to address this issue, a reflection process 
may be used on subject object 18 to determine its name, 
interfaces and list of methods and then to directly 
generate the byte codes into a .class file, subject 
class 19. The byte codes are the executable code stored in 
a .class file. The .class file can then be loaded into the 
computer system with the class loader. This embodiment 
eliminates the need to parse the .class file, create a 
.java source code file, and shell out the .java file to a 
compiler since the code generation process occurs as part 
of the dynamic generation of remote proxies. This entire 
process of dynamic generation of remote proxies will be 
discussed in detail with reference to FIGURES 2, 3 and 4. 

Referring to FIGURE 2, the process of determining if 
a remote proxy is necessary is invoked via a request from 
local object 20 for access to subject object 18. The 
method begins at step 24 where local object 20 on client 
system 14 requests access to subject object 18 on server 
system 12. This request could be for any object whether it 
is local or remote and in a different address space. The 
system of the present invention generates and utilizes 
remote proxy objects in all inter-object communication to 
provide additional processing support. Thus, any 

communication between objects, regardless of their 
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location, utilizes remote proxy objects. These remote 
proxy objects act as a middle man between the requested 
object and the requesting object to provide additional 
processing functionality which may include increased 
5 security. 

Referring again to FIGURE 2, the method then proceeds 
to step 26 where the requested object is located on either 
client system 14 or server system 12. The method proceeds 
to step 30 where a determination is made regarding the need 

10 for a remote proxy class. If remote proxy class 23 already 

exists on client system 14, then the method terminates 
since remote proxy classes are not removed from client 
system 14 until the distributed object management system 16 
is shut down. However, if remote proxy class 23 does not 

15 exist on client system 14, the method then proceeds to step 

32 where remote 'proxy class 23 is generated on client, 
system 14 based on the name, interfaces and methods of 
subject object 18 which may reside on either server system 
12 or client system 14. The' method for generating these 

20 remote proxies is described in detail with reference to 

FIGURES 3 and 4. 

Figure 3 is a functional diagram of the portions of 
distributed object management system 16 that are used to 
create remote proxy classes as necessary. Remote proxy 

25 generation control module 34 is invoked at step 32 in 

FIGURE 2. When the distributed object management system 16 
invokes the remote proxy generation control module 34, the 
method described previously has already determined that the 
remote proxy class 23 does not yet exist on client system 

30 14. Remote proxy generation control module 34 generates 

remote proxy 22 on client system 14 so local object 20 can 
communicate with subject object 18 via distributed object 
management system 16. 

As previously discussed, in object oriented 

35 programming, an object is an instance of a class. Classes 
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may be defined in a class hierarchy where each class 
inherits the attributes of all of its ancestors. 
Inheritance is a concept which maps related classes onto 
each other in a hierarchical way. This allows a descendant 
of a class to inherit all of its variables and methods from 
its ancestors as well as create its own. The immediate 
ancestor of a class is known as its superclass. Therefore, 
in order to determine all of a class's attributes, all of 
the class's ancestors, or superclasses, must be determined. 

To fully define a remote proxy for a subject object, 
remote proxies must be generated for each of the subject 
object's superclasses. By generating these superclass 
remote proxies, the remote proxy for subject object will 
inherit all of the variables and methods of its ancestors, 
or superclasses. An alternative to generating superclass 
remote proxies includes adding all of 'the superclass 
methods and interface requirements to the remote proxy 
class. By adding the superclass information to the remote 
proxy class, the need for generating superclass remote 
proxies is eliminated. 

Referring again to FIGURE 3, remote proxy generation 
control module 34 first invokes reflection engine 36 to 
determine information regarding subject class 19. The 
process of reflection operates on subject class 19 which is 
the Java .class file for subject object 18. Although for 
illustrative purposes, subject object 18 and its Java 
.class file, subject class 19, exist on server system 12, 
subject class 19 could exist on either client system 14 or 
server system 12. Therefore, the dynamic generation of 
remote proxy classes as described in the present invention 
could take place on either client system 14 or server 
system 12 . 

Reflection is a process that determines what an object 
can do, how it is defined, and how it communicates with 
other objects. Reflection mirrors the public view of an 
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object to collect information to facilitate the creation of 
proxies which resemble objects on the public view, but are 
very different internally, or privately. The public view 
of an otnect represents the information external objects 
5 must know j n order to communicate with the first object. 

Proxies r.ee-J to be reflections, or duplicates on the 
surface, o: objects since proxies perform specific tasks 
such as controlling access to or communications with the 
objects they represent. Thus, proxies need to look like 

10 the object or. the outside, but on the inside, proxies 

contain unique computer code to accomplish their assigned 
function. The reflection process is only concerned with 
determining the public view of an object. Therefore, the 
information determined by the reflection process includes 

15 the following: name; list of implemented interfaces; list 

of methods; and superclass information. 

Continuing with FIGURE 3, reflection engine 36 issues 
queries against subject class 19, which is the .class file 
for subject object 18, to determine each of subject 

20 class 19 superclasses, its name, its interfaces, and each 

of its methods. The results of these queries are 
temporarily stored within remote proxy generation control 
module 34 as JClass information 38. JClass information 38 
is a temporary storage area which defines the name, 

25 superclasses, interfaces, and methods of subject class 19. 

JClass information 38 would also include the name, 
interfaces, and methods of each of subject class 19 
superclasses . 

If subject class 19 has superclasses, a remote proxy 
30 may be first generated for each superclass using the system 

and method described with reference to the present 
invention. After the superclass remote proxies are 
generated, JClass information 38 contains the name, 
interface, and list of methods for subject class 19. An 
35 alternate methodology for providing superclass methods and 
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interfaces for the remote proxy class is to add all 
superclass method and interface information to the remote 
proxy class. By doing this, the need for separate 
superclass remote proxies is eliminated, 
5 Once the name, interface, methods, and superclass 

: • trrr.ut i on are determined for subject class 19, a 
** -T .;r; i ;u l i on enabling module 40 adds to JClass information 
* r.. .".-rp-jter code necessary for remote proxy object 22 
- M r;.:i;cjte with subject object 18 via distributed 
10 : • t n.i:.c*.;cment system 16. The communication enabling 

-1v inserts the computer code into JClass information 
which -s the definition of all the information that 
:--:-toie proxy object 22 needs to function within distributed 
: ]ec: management system 16. 
15 Cir.cc o remote proxy's purpose is to communicate with 

<: subject object which may exist either in a different 
uddress space or in the same address space, the remote 
proxy contains essentially only the following information: 
interfaces identical to the subject object; a list of 
20 methods identical to the subject object; and computer code 

necessary for the remote proxy to communicate with the 
subject object. In an alternate embodiment of the present 
invention, the remote proxy would contain all of the 
information mentioned above and the interfaces and methods 
25 of all of the subject object's superclasses. 

At this point, JClass information 38 contains subject 
object's 18 name, interfaces, methods, and the computer 
code necessary for communications within distributed object 
management system 16. JClass information 38 could also 
30 contain the superclass information for subject object 18. 

The next function invoked by remote proxy generation 
control module 34 is byte code generator 42. The purpose 
of byte code generator 42 is to directly generate the 
executable code corresponding to JClass information 38. 
35 JClass information 38 is the definition of the Java class 
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of which remote proxy object 22 is an instance. That is, 
JClass information 38 is the definition of remote proxy 
class 23. Byte code generator 42 reviews JClass 

information 38 and generates the corresponding byte codes, 
5 or executable code, into remote proxy class 23 which is a 

Java .class file. As previously discussed, a Java .class 
file is executable code which defines a Java class. 

Byte code generator 42 is a collection of Java classes 
which are capable of taking the description of the needed 

10 proxy class in JClass information 38 and directly 

generating the executable Java code in memory. The 
function of byte code generator 42 is similar to that of a 
Java compiler. Like a Java compiler, byte code 

generator 42 generates executable Java code. However, the 

15 inputs are very different. A compiler requires a source 

code file which is a string of bytes which is the sequence 
of statements for a Java object definition. The string of 
bytes is parsed by the Java compiler and translated into 
executable Java code. In contrast, byte code generator 42 

20 takes general information regarding the needed Java object 

and directly generates executable Java code without the 
need for the intermediate step of creating a Java source 
file. This technique yields considerable time savings 
since several steps are omitted. For example, like a Java 

25 compiler, byte code generator 42 generates a hexadecimal 

"CAFEBABE" to indicate to the Java virtual machine that a 
Java .class file begins at that point in memory. Byte code 
generator 42 is constructed in such a way that the byte 
codes are generated in the sequence required by the Java 

30 virtual machine. 

For each Java construct, byte code generator 42 writes 
the appropriate header information and hexadecimal byte 
codes representing the Java construct into computer memory. 
Thus, there is a block of code, or hexadecimal bytes, for 

35 each Java construct. As described above, JClass 
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information 38 contains the computer code necessary for 
communications within distributed object management 
system 16. Byte code generator 42 translates this 
communications information into byte codes recognizable to 
the Java virtual machine. When byte code generator 42 
terminates, the string of hexadecimal bytes necessary to 
define the proxy class has been stored in memory as remote 
proxy class 23 which is an executable Java .class file. 
Remote proxy class 23 has a unique name which is derived 
from subject class 19 name. For example, if subject 
class 19 is named "Foo. class", its remote proxy class 23 
name would be "Foo Proxy . class" . 

Before remote proxy class 23 can be used, it must be 
loaded onto client system 14 utilizing a class loader 46. 
Class loader 4 6 may comprise any number of suitable 
programs which exist in typical object oriented programming 
environments. " The class loader 4 6 will then create " remote 
proxy object 22 which is an instance of remote proxy 
class 23 generated by byte code generator 42. 

FIGURE 4 is a flow diagram that illustrates the 
process of generating a remote proxy when invoked by step 
32 in FIGURE 2 and as represented in general by the block 
diagram in FIGURE 3. The method begins at step 48 where 
the reflection engine 38 queries subject class 19 to 
determine its superclass. The method then proceeds to step 
50 where a determination is made regarding the existence of 
a superclass for subject class 19. If a superclass is 
found for subject class 19, then the method proceeds to 
step 52 where a determination is made regarding the 
existence of the remote proxy class on client system 14 
representing subject class' 19 superclass. If a remote 
proxy class does not exist for subject class' 19 
superclass, the method proceeds to step 54 where the remote 
proxy class is generated for subject class 1 19 superclass 
by recursively invoking the remote proxy generation control 
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module 34. Thus, step 54 recursively invokes the method 
illustrated in FIGURE 4. 

Referring to step 52, if the remote proxy class does 
exist on client system 14 for subject class' 19 superclass, 
5 then the method proceeds to step 56 (described below) since 

r-note proxy classes already exist for all of subject 
r oct's 18 superclasses. 

Irs an alternate embodiment of the present invention, 
. r " t n ct recursively generating remote proxy classes for 

10 • . -r. c: subject class 19 superclasses, the interfaces and 

*! ■ mods of each of subject class 19 superclasses are stored 
. :. JClars information 38 and are later used in the 
icierciUori of remote proxy class 23- In the alternate 
••-•.bodiment , steps 4 8-54 would not exist in their current 

15 :orm . Instead, these steps would consist of determining 

the names, interfaces, and methods of all of subject 
class 19 superclasses and storing the information in JClass 
information 38. 

Referring to step 50 if a superclass does not exist 

20 for subject object 18, then the method proceeds to step 56 

where reflection engine 36 queries subject class 19 to 
determine subject class' 19 name and interface. The method 
then proceeds to step 58 where reflection engine 38 queries 
subject class 19 regarding its methods. Reflection engine 

25 36 issues queries for each of subject class' 19 methods 

until all methods are determined. For each of subject 
class' 19 methods, the software system determines the 
method name, return type, parameters, and exceptions and 
stores the information in JClass information 38. 

30 The method then proceeds to step 60 where reflection 

engine 36 creates JClass information 38 from the name, 
interface, and methods information determined in steps 56 
and 58. The method then proceeds to step 62 where 
communication enabling module 40 inserts in JClass 

35 information 38 the computer code, in the form of an 
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expression tree, necessary for remote proxy object 22 to 
communicate with subject object 18 via distributed object 
management system 16. 

The method then proceeds to step 64 where byte code 
5 generator 42 generates the executable code representing 

JClass information 38 into remote proxy class 23. The 
method then proceeds to step 66 where class loader 46 loads 
remote proxy class 23 onto client system 14 where it is now 
available for use. The method then proceeds to step 68 

10 where remote proxy object 22 is generated as a new instance 

of remote proxy class 23 which was loaded in step 66. 

According to the teachings of the present invention, 
a software system is provided that allows for the dynamic 
generation of remote proxy classes. The advantages of 

15 dynamic generation of remote proxy classes includes reduced 

system development time, reduced system compile and build 
time, reduced system modification time, and reduced system 
storage requirements. Remote proxy classes are generated 
as needed at run time. Once a remote proxy class is 

20 generated, it continues to exist until the system is shut 

down. Therefore, the software system is only required to 
generate a particular remote proxy class once during a 
session of the software system. 

Although the present invention and its advantages have 
been described in detail, it should be understood that 
various changes, substitutions and alterations can be made 
therein without departing from the spirit and scope of the 
invention as defined by the appended claims. 
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WHAT IS CLAIMED IS 



1. A software system for dynamic generation of 
remote proxy classes within an object oriented distributed 
processing environment, comprising : 

a client system operable to request services from a 
server system located remotely from the client system and 
communicating with the client system using a distributed 
computer network; 

a distributed object management system operating over 
the distributed computer network and operable to allow 
communications between the client system and the server 
system; and 

a remote proxy generator operating within the 
distributed object management system and operable to 
dynamically generate at run time remote proxy classes as 
needed by the distributed object management system to 
facilitate communications within the object oriented 
distributed processing environment . 
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2. The software system of claim 1, wherein the 
remote proxy generator further comprises: 

a reflection engine operable to determine the name, 
interfaces, methods and superclass information of a 
requested object within the object oriented distributed 
processing environment for use in creating the remote proxy 
class; 

a communications enabling module operable to aid in 
creating the remote proxy class by inserting within the 
remote proxy class computer code required for 
communications between objects within the object oriented 
distributed processing environment; and 

a byte code generator operable to generate the 
executable computer code representing the determined name, 
interfaces , methods , superclass information and 
communications computer code for the remote proxy class. 

3. The software system of claim 1, further 
comprising a determination module operable to determine if 
a remote proxy class needs to be generated in response to 
a request for services from the client system by 
determining if a request for services requires access to an 
object in a different address space and by determining if 
a remote proxy class has already been generated for the 
object existing in a different address space. 
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4. The software system of claim 1, further 
comprising a determination module operable to determine if 
a remote proxy class needs to be generated in response to 
a request for access to a requested object by determining 
if a remote proxy class has already been generated for the 
requested object, 

5. The software system of claim 1, further 
comprising a class loader operable to load the generated 
remote proxy classes onto the client system. 

6. The software system of claim 1, wherein the 
remote proxy generator is utilized by the object oriented 
distributed processing environment to generate remote proxy 
classes for all inter-object communication including both 
inter-address space and intra-address space ; communications . 
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7. A software system for dynamic generation of 
remote proxy classes within an object oriented distributed 
processir.n envi rcnment, comprising: 

a cli'-r.: nystem operable to request services from a 
5 server syr^'/n. located remotely from the client system and 

communicainicj with the client system using a distributed 
computer net wo r k ; 

a distributed object management system operating over 
the distributed computer network and operable to allow 
10 communicatioriii between the client system and the server 

system; 

a determination module operable to determine if a 
remote proxy class needs to be generated in response to a 
request for access to a requested object by determining if 

15 a remote proxy class has already been generated for the 

requested object; 

a reflection engine operable to determine the name, 
interfaces, methods, and superclass information of a 
requested object within the object oriented distributed 

20 processing environment for use in creating the remote proxy 

class; 

a communications enabling module operable to aid in 
creating the remote proxy class by inserting within the 
remote proxy class computer code required for 

25 communications between objects within the object oriented 

distributed processing environment; 

a byte code generator operable to generate the 
executable computer code representing the determined name, 
interfaces, methods, superclass information, and 

30 communications computer code for the remote proxy class; 

and 

a class loader operable to load the generated remote 
proxy classes onto the client system. 
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8. A method for dynamic generation of remote proxy 
classes within an object oriented distributed processing 
environment, comprising : 

providing a client system operable to request services 
5 from a server system located remotely from the client 

system and communicating with the client system using a 
distributed computer network; 

providing a distributed object management system 
operable to allow communications between the client system 
10 and the server system; and 

generating a remote proxy class on the client system 
when an object on the client system requests access to 
another object within the object oriented distributed 
processing environment and a remote proxy class does not 
15 exist on the client system for the requested object. 

9. The method of claim 8, wherein the step of 
generating a remote proxy class further comprises the steps 
of: 

reflecting the requested object requiring a remote 
5 proxy class to determine the requested object's name, 

interfaces, methods, and superclass information for use in 
creating the remote proxy class; 

inserting within the remote proxy class the computer 
code necessary for communications between a remote proxy 
10 object on the client system and the requested object within 

the object oriented distributed processing environment; and 
generating the executable code representing the 
determined name, interfaces, methods, superclass 
information, and communications computer code for the 
15 remote proxy class. 
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10. The method of claim 8, further comprising 
determining if a remote proxy class is required in response 
to a request for services from the client system to the 

5 server system by determining if a request for services 

requires access to an object in a different address space 
and by determining if a remote proxy class has already been 
generated on the client system for the object existing in 
a different address space. 

11. The method of claim 8, further comprising 
determining if a remote proxy class is required in response 
to a request for services from the client system by 
determining if a remote proxy class has already been 

5 generated on the client system for the requested object. 

12. The method of claim 8, further comprising 
utilizing the class loader to load the generated remote, 
proxy classes onto the client system. 
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13. A method for dynamic generation of remote proxy 
classes within an object oriented distributed processing 
environment , comprising: 

providing *j client system operable to request 
services : : >n a server system located remotely from 
the client system and communicating with the client 
system usina a distributed computer network; 

providing a distributed object management system 
operable to allow communications between the client 
system and the server system; 

determining if a remote proxy class is required 
in response to a request for services from the client 
system by determining if a remote proxy class has 
already been generated on the client system for the 
requested object; 

reflecting the requested object requiring a 
remote proxy class to determine the requested object's 
name, interfaces, methods, and superclass information 
for use in creating the remote proxy class; 

inserting within the remote proxy class the 
computer code necessary for communications between a 
remote proxy object on the client system and the 
requested object within the object oriented 
distributed processing environment; 

generating the executable code representing the 
determined name, interfaces, methods, superclass 
information and communications computer code for the 
remote proxy class; and 

utilizing the class loader to load the generated 
remote proxy classes onto the client system. 
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(57) Abstract 

A software system is disclosed which provides for dynamic generation of remote proxy classes at run time through a distributed object 
management system (16). The software system provides for a client system (14) and server system (12) which communicate via distributed 
object management system (16) which operates over a distributed computer network to allow communications between client system (14) 
and server system (12). Any inter-object communication will invoke a remote proxy generation control module (34) if a remote proxy 
class (23) does not already exist for the requested subject object (18). A remote proxy generation control module (34) is provided which 
first invokes reflection engine (36) to determine the applicable information of subject class (19). Next, a communication enabling module 
(40) determines and inserts the appropriate computer code to allow local object (20) to communicate with subject object (18) utilizing 
remote proxy object (22). After the system determines what information is required by remote proxy class (23), byte code generator (42) 
automatically generates the executable code containing remote proxy class (23). Finally, class loader (46) loads remote proxy class (23) 
onto the system and creates a new instance which is remote proxy object (22). 
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